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(54) Customer worth differentiation by selective activation of physical instrumentalities within 
the casino 

(57) A system and method for differentiating cus- 
tomers according to their worth to the casino. Customer 
information is accumulated at each affiliated casino 
through one or more LAN-based management systems, 
updated to a central patron database (CPDB) that is 
coupled to each casino LAN through a WAN, and made 
availat>le to each affiliated casino property as needed. 
Customer accounts are automatically activated and pro- 
vided with data from the CPDB when a customer from 
one casino property first visits an affiliated casino prop- 
erty. Customer accounts are updated with status infor- 
mation based on the customer's worth to the casino. 
Customer accounts are updated with new activity data 
whenever a management system associated with the 
casino receives customer data from input devices, such 
as card readers, workstations, and dumb terminals, 
located at various venues throughout the casino. Cus- 
tomers are awarded points, based on their tracked 
activity at all affiliated casino properties. Customers 
also have theoretical win profiles. Customer status may 
be based on accumulated points or the theoretical win 
profile. When the customer Is recognized at a gaming 
machine, or any location having a suitable card reader, 
the customer's status is determined in the ci^omer 
account. For a special status customer, a physical 
instrumentality is activated for the benefit d the cus- 
tomer, such as a telephone, light, lockable cabinet, or 
the like. Distinguished services may also be provided 
once the special status customer is recognized. 
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Description 

Related Patent Application 

5 [0001] This patent application is a continuation-in-part of U.S. Patent 5.761 ,647, entitled National Customer Recog- 
nition System and Method, filed on May 24. 1996 and issued on June 2. 1998, and assigned to the same assignee as 
the present application. 

Background of the Invention 

10 

[0002] Technical Field This invention relates to the field of systems for tracking customer activity at casinos, and In 
particular, to systems for tracking customers' gaming and non-gaming activity across affiliated casino properties, for use 
in customer recognition and marketing programs. 

[0003] Background Art Substantially all casinos have implemented some form of customer tracking to identify and 
15 reward their valuable customers. These tracking programs often use the betting activity of a customer as the basis for 
awarding the customer complementary rooms, meals, event tickets, and the like ("comps"). Typically, these tracking pro- 
grams are implemented by providing each customer with a casino membership card which includes a machine readable 
identification number specific to the customer Each identification number has an associated customer account that is 
stored in the casino's computer system and updated to reflect customer activity Customers need only insert their cards 
20 In slot machines or card readers associated with gaming tables or give their cards to a casino employee to have their 
betting activity monitored and reflected in their accounts. Customer cards may also be used to track customer activity 
at casino venues, such as special events, showrooms, and hotels, through card readers and computer terminals 
manned by casino employees. 

[0004] The growth of the gaining industry has created new challenges to the way in which customer tracking programs 

25 are implemented. Many states and tenitories have recently legalized casino gambling, and companies have built casino 
properties at these new gaming locations to meet the demand for gaming facilities. Despite the increased number of 
casino properties affiliated with a company, conventional casino management practices continue to treat these casino 
properties as autonomous, decentralized entities that compete with each other for valuable customers. In particular, 
customer tracking at each casino property is typically controlled by local management, and few if any attempts have 

30 been made to coordinate customer information across affiliated casino properties. For example, each casino has its 
own system that tracks betting data on the casino's customers. The property ti-eats this betting data as confkjential, in 
order to prevent competing casinos, including tfiose affiliated with the property, from luring away valuable customers. 
Thus, customer tracking programs at affiliated properties remain fragmented, and conventional management practices 
provide little incentive to coordinate data accumulated by these tracking programs. 

35 [0005] Even if a casino company was to attempt some coordination of customer tracking programs at its affiliated casi- 
nos, the systems cun-ently in place at various casino properties are too localized to integrate easily Casino manage- 
ment systems are typically custom designed for each casino property, the customer data is limited to selected customer 
activity at the specific casino property, and ttie customer data accumulated by different computer systems within the 
same casino is often in different, incompatible formats. Thus, while each casino has useful data for its regular custom- 

40 ers. there is no ready means for consolidating this data or making it available conveniently for use at other casinos. In 
short, there are both operational and technical ban-iers to coordinating customer tracking programs at Indivkiual casino 
properties into national, conpany-wide tracking and marketing programs. 

[0006] Another limitation of conventional casino management systems is that tiiey do not take adequate steps to dif- 
ferentiate the worth of a customer to the casino on the basis of the customer's gaming activities. In particular, conven- 
45 tlonal systems do not adequately provide the customer witii the use of various physical instrumentalities that enhance 
the customer's experience, based on the customer's worth to the casino. 

Summary of the Invention 

50 [0007] The present invention is a system and method for implementing a customer tracking and recognition program 
that provides various enhanced physical instrumentalities and distinguished services to a customer based on the cus- 
tomer's wortii to tiie casino. The customer's worth is biased on tiie customer's gaming and non-gaming activity alike, 
preferably at all casino properties affiliated with a casino conpany. txit also at individual casinos. Each customer is 
issued an identity card which is associated with h's or her own customer data in a customer datat>ase. The card enables 

55 the customer to be immediately recognized any tame the card is input into a suitable card reading device coupled to the 
system. The present invention allows o^omer data to be accumulated across all casino properties and made available 
at any casino property without oveiburdening tiie individual casino properties' computer systems with unnecessary 
data. In addition, the present invention allows the customer to be provided with distinguished services or physical instru- 
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mentalities based on the customer's worth to the casino. 

[0008] A system in accordance with the present invention comprises a local area network (LAN) at each affiliated 
casino property and a wide area network (WAN) for coupling data among the casino LANs. A management system 
associated with each casino LAN receives customer data from card readers, workstations, and dumb terminals, located 

5 at various venues throughout the casino and couples the received data to a database that is accessible to all affiliated 
casino properties. In a preferred embodiment of the invention, a central patron database (CPDB) comprising customer 
accounts from all of the casino properties is supported on a central LAN that is coupled to the casino LANs through the 
WAN. In this embodiment, the management system may be a single, centralized system supported on the central LAN, 
a distributed system comprising local management systems associated with each casino LAN, or a hybrid system 

10 including both centralized and distributed components. The preferred configuration for the management system will 
depend on the data capacity of the WAN arxl the sizes of the various casino properties. The CPDB stores information 
about each customer. A customer's worth may be established in the CPDB as status data indicating the status of the 
customer. The status of the customer may be based on accumulated points that a customer earns from betting and 
other activity at the various casino properties or from a theoretical win profile of the customer Each casino may also 

15 maintain a local database of customer accounts, Including the status data based on points earned at the casino or a 
locally generated theoretical win profile. 

[0009] In operation, a customer presents an identity card to a card reader when initiating a gaming or non-gaming 
activity. The system recognizes the customer from the identity card and obtains customer data of the customer from the 
CPDB or from a local database, including data indicating the customer's status. The present invention then provides 

20 enhanced physical instrumentalities to the customer based on the customer's status. 

[001 0] There are many different types of physical instrumentalities that may be provided to the customer to enhance 
his or her experience at the casino. For example, when a valuable customer is recognized at a slot machine, a highly 
visible light on top of the slot machine may be activated, thereby alerting both casino employees and other customers 
that this valuable customer is present. Differentiation of the customer in this manner also enables the casino to provide 

25 distinguished services to the customer, such as improved food and beverage services, and slot change or slot fill serv- 
ices. 

[001 1 ] Another example of an enhanced physical instrumentality is the activation of a telephone installed near a gam- 
ing machine being used by the customer. This allows the vali^le customer to make telephone calls without leaving the 
gaming machine, as other customers would have to do. Yet another example is the activation and enabling of a tockable 

30 storage compartment at the gaming machine to allow the customer to store personal items therein. Finally, yet another 
example of enhanced physical instrumentality is the automatic unlocking of a door to a privileged facility, such as a VIP 
club, when the customer's card is recognized arxj the customer's status or worth suitably determined. 
[001 2] It will be appreciated that the present invention differs from conventional fee-based membership systems and 
point-based systems, in that it provides activation of physical instrumentalities directly based on recognition of a cus- 

35 tomer*s status, and hence worth, from use of the customer's identity card. Unlike prior systems, in the present invention 
customer status is based on the customer's worth directly, and thus as the customer's wortii increases due to the cus- 
tomer's gaming activity, then access or activation of the physical instrumentalities is provided. Also, conventional sys- 
tems do not provide immediate activation of physical instrumentalities tiiat directly enhance the customer's gaming 
experience. 

40 [001 3] Tlie term "affiliated casinos", as it is used throughout this disclosure, is intended to indicate any of a number 
of different relationships between casino properties. For example, casinos may be affiliated tiirough common ownership 
by a parent company, they may be owned by different companies operating under a cooperation agreement, or they 
may be under contract with the same provider for customer tracking services. 

45 Brief Description of the Drawings 

[0014] 

Fig. 1 is an overview of a national customer recognition system in accordance witii the present invention. 

so 

Figs. 2A, 2B. and 2C are block diagrams of the various system modules supported in the central datat^ase server 
and a casino property LAN. respectively, for different configurations of the customer recognition system. 

Fig. 3 is an overview of a casino lAK indicating connections b^een the various input devices and distributed 
55 management systems supported on the casino LAN. 

Fig. 4. is a flow chart representing a method for ta-acking customer activity across all affiliated casino properties in 
accordance with the present invention. 
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Fig. 5 is a block diagram of the system modules supported on casino LANs where a distributed patron database 
and management systems are employed. 

Fig. 6 is a block diagram of a network system incorporating a messaging system in accordance with the present 
5 invention. 

Fig. 7 is a block diagram of the messaging system for the network system shown in Fig. 6. 

Fig. 8 is a block diagram of the components of a service application supported by transaction services of the open 
10 system network. 

Fig. 9 is a.block diagram showing the relationship between the ASCII Definition File and the defined data structures 
and data dictionaries generated from the ASCII Definition File. 

75 Rg. 1 0 is a representation of an ACDS deJined data structure for communications between an RPQ application and 
the messaging system of the present invention. 

Rg. 11 is a more detailed block diagram of the service application of Fig. 8. 
20 Rg. 12 is a block diagram of the network system of Rg. 6, including a security service in the gateway server. 
Rg. 13 is an illustration of a slot machine with a selectively activateable light and telephone features. 
Rg. 14 is a block diagram of the slot machine in accordance with the present invention. 

25 

Detailed Description of the Invention 

[0015] The present Invention is described in detail for a configuration of the national customer recognition system 
comprising a central patron datatsase (CPDB] on a central LAN that is coupled to local management systems associ- 

30 ated with each casino LAN. This configuration is particularly useful for companies that have already invested significant 
capital in local management systems for their casino properties, because it leverages these systems into a company- 
wide network through the addition of a CPDB. The system configuration employing a centralized management system 
with a CPDB and the system configuration employing distributed management and database systems are discussed in 
conjunction with Figs. 2C and 5, respectively. 

35 [GDI 6] Referring first to Rg. 1 , there is shown an overview of a computer network 100 for implementing the system 
and method of the present invention. Computer system 100 is shown comprising a central database LAN 110 and 
casino LANs 120(1)-120(n). each of which is associated with one of the affiliated casino properties. Central database 
LAN 110 and casino LANs 120(1)-120(n) are coupled through a wide area network (WAN) 102. Typically, central data- 
base LAN 1 10 will be located at a central facility of the casino company. 

40 [0017] In the following discussion. LAN 120 designates any one of casino LANs I20{l)-120{n) unless othenyise 
noted. Similar notation, I.e. unindexed reference numbers, is used for the various components of LANs 120(1)-120(n). 
It is understood that in a typical application, computer system 1 00 includes one or more LANs 1 20 for each casino prop- 
erty affiliated with the parent casino company, and all l-ANs 120 communicate with central database LAN 1 10 through 
WAN 102. This configuration allows each LAN 110, 120 to operate in a substantially independent manner until it 

45 requires access to data available on a different network. 

[0018] In the disclosed ennbodiment, central database LAN 1 10 comprises an Ethernet 106 to which a central data- 
base server 1 12 and a marketing support sender 114 are connected. An optional server 1 1 6 on LAN 1 10. supports a 
centralized management system (CMS 284, Rg. 2C) in the fully centralized configuration of the national customer rec- 
ognition system. A token ring 108 is also shown connecting Ethernet 106 to WAN 102. Token ring 108 typically includes 

50 additional nodes, such as workstation 1 1 8. for marketing and local processing. Central database server 112 includes a 
central patron database (CPDB 220, Fig. 2A), comprising customer accounts based on data originating at each casino 
property affiliated with the company. For the embodiment employing distributed management systems (CMS 234, Rg. 
2B). central database server 1 12 is the only essential node on LAN 1 10. However, it is likely that in most implementa- 
tions, other nodes such as workstations 1 18 and marketing support sender 1 14 will be available for marketing analysis 

55 using data derived from CPDB 220. 

[0019] In the prefen'ed emixxliment of tiie invention, marketing support server 114 includes customer data from 
CPDB 220 stored in a manner that facilitates its use for marketing purposes. For example, customer data may be sorted 
and stored in server 1 1 4 according to customer groups segmented by profitability, principal gaming location (property), 



4 



BNSOOCID: <EP 096121 3A2.L> 



EP0 961 213 A2 



or other marketing alteria. On the other hand, customer data in server 1 12 is stored in a manner that facilitates rapid 
access by customer ID or name. 

[0020] Referring now to Fig. 2A. there Is shown a block diagram of various systems supported on central database 
server 112. These include an operating system (OS) 212. a database management system (DBMS) 214, a transaction 

5 management system 216'. and central patron database (CPDB) 220. Transaction management system 216' supports 
messaging between casino LANs 120 and sen/ices on central LAN 110. such as CPDB 220. allowing them to exchange 
data as necessary In the disclosed embodiment, central database server 112 is an NCR 3555 computer. OS 212 is 
UNIX SVR4, DBMS 214 is Informix 7.1, and transaction management system 216' is TOP END, available from 
AT&T/NCR. Central LAN 110 employs TCP/IP communication protocol for communications among the nodes of Ether- 

70 net 106 and token ring 108. 

[0021 1 Referring again to Fig. l . each casino property LAN 1 20 is shown with the same basic structure. For purposes 
of illustration, LAN 120 is shown comprising a token ring 122 to which are connected computers 124, 144. 154. a gate- 
way server 1 26, and workstations 1 28, 1 48. Dumb terminals 1 32 and PCs 1 72, which are connected directly to compu- 
ter 124, are typically associated with gaming tables (Fig. 3). and slot machines 130 are coupled to computer 124 

15 through a slot computer 154 and token ring 122. Thus, all gaining-related activity is routed to computer 124. At the 
selected computers, terminals and PCs. are coupled card readers 724 for reading a customer's identity card. In addi- 
tion, computers 124. 144, 154 or PCs 172 coupled to card readers 724 maybe located at other locations at the casino 
property such as hotel check-in, restaurants, entertainment facilities, privileged facilities, and any other location at 
which it is desirable to recognize a customer via their identity card and provide some form of enhanced service or acti- 

20 vation of a physical Instrumentality that distinguishes the customer from other customers based on the customer's 
worth. 

[0022] A person skilled in the art will recognize that LANs 120 associated with different properties may vary from this 
structure in order to accommodate special needs at different casino properties, without altering the nature of the 
present invention. For example, a casino property lacking a hotel or event venue would not include computer 144 or 
25 workstation 1 28 and their associated lodging and event management systems, respectively. In addition, other LAN pro- 
tocols, including Ethernet and the like, may be used instead of token ring 122. 

[0023] Referring now to Fig. 28. there is shown a detailed block diagram of LAN 1 20. indicating a casino management 
system (CMS) 234. lodging management system (LMS) 238. and event management system (EMS) 240. associated 
with various LAN nodes (computers 124. 144. and workstations 128. respectively), for monitoring, tracking, and control- 

30 ling different areas of casino operations. In a preferred embodiment of the invention. CMS 234 includes Report Program 
Generator (RPG)-based programs for on-line transaction processing (OLTP) applications. These applications consoli- 
date activity data at the casino property related to gaming, and access CPDB 220 to retrieve or store data, as neces- 
sary For example, dumb terminals 132 and PCs 172 communicate customer gaming activity data from gaming tables 
to CMS 234. Dumb terminals 132 and PCs 172 may also be used for tracking customers' currency and marker trans- 

35 actions and for accessing gaming activity that is tracked through a slot computer 1 54. 

[0024] Automatic bet tracking at slot machines 1 30 Is monitored by a slot monitoring system (SMS) 262 on computer 
154, which couples accumulated bet tracking data to CMS 234 through token ring 122, In the preferred emt>odiment. 
bet tracking is accomplished through a card reader 724 associated with slot machines 130. other gaming machines, or 
gaming table 134. (For the purposes of this disclosure, examples regarding bet tracking and customer recognition will 

40 be made with reference to slot machines 130, however it is to be understood that the same principles of operation of 
the present invention apply to any other type of gaming machine or gaming table.) 

[0025] A customer inserts his or her identity card in the card reader 724 to Initiate bet tracking and removes it to ter- 
minate bet tracking. When a customer inserts the identity card into the cand reader 724, the SMS 262 sends a message 
to the slot machine 130 with information retrieved from the CPDB 220 or a local database in CMS 234, indicating vari- 
es ous customer data, such as the customer's name, account nunrtoer. total points accumulated in the customer's account, 
the customer's status, and the like. The slot machine 1 30 may display some of this information to the customer, such 
as the point balance. The slot machine 130 may selectively activate some physical instrumentality near the machine 
t>ased on the customer's status data, which physical instrumentality distinguishes the customer from other customers 
and preferably enhances the customer's gaming experience. A customer's betting activity at slot machine 130 or the 
so like is accumulated in SMS 262 until the session is terminated or an account status is requested by CMS 234. at which 
time the data is transfen-ed to CMS 234 via LAN 120. 

[0026] LAN 120 may optionally include a pit tracking system (PTS) 258 to automatically track customer activity at 
gaming tables 1 34. PTS 258 is shown supported on a computer 1 74, which couples customer activity data to CMS 234 
through LAN 120. PTS 258 uses card readers 724 associated with player positions at gaming tables 134 to track cus- 
ss tomers' betting activity. Estimates of betting activity are based on a customer's time at a gaming table and the minimum 
bet at the table. Systems for automatically tracking betting activity at slot machines and gaming tables are well known 
in the art and are not described in greater detail here. 

[0027] In the preferred embodiment of the invention, a lodging management system (LMS) 238 is maintained on com- 
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puter 144. However, there is no reason that CMS 234. LMS 238 and any other management systems could not be sup- 
ported on the same computer or some different combination of computers. LMS 238 comprises the software necessary 
for managing hotel operations within the casino, including reservations, room service, and other activities associated 
with hotel operations. In a preferred embodiment of the invention. LMS 238 communicates with CMS 234 to search 
5 locally for selected customer information available on that system. However, LMS 238 may include its own local data- 
base for customer data. Where a terminal or computer providing LMS 238 access is located, such as at a hotel front 
desK card readers 724 may be located to allow a customer's identity card to be read, the customer recognized, and 
provided with distinguished services if appropriate. 

[0028] Also shown in Fig. 2B is an event management system (EMS) 240 on workstation 128 and a restaurant/retail 
10 point of sale system (POS) 244 coupled to workstation 1 48 and card reader 724. EMS 240 comprises software for han- 
dling ticketing information, reservations, and sales. POS 244 comprises accounting software for operating restaurants 
and retail venues within the casino property as well as software for transmitting charge information to other manage- 
ment systems. For example, data relating to meals charged to rooms or redeemed meal comps are coupled from POS 
244 to LMS 238 and CMS 234. respectively, through LAN 120. 
15 [0029] The primary role of gateway server 126 is to provide a link between selected nodes of LAN 120 and central 
datat«se server 1 1 2 through WAN 102 and LAN 11 0. For this purpose, gateway sen/er 126 includes a LAN/WAN inter- 
face 280 that couples data packets between the communication protocols of LAN 120 and WAN 102 and another 
instance of transaction management system 216 that routes data packets between management systems 234. 238, 
240 and selected services in CPDB 220. In the preferred embodiment of the invention, CMS 234 on computer 124 
20 accesses CPDB 220 through transaction management system 216'. 216. while LMS 238 and EMS 240 access CPDB 
220 through CMS 234, as discussed below. An interface module 235 in CMS 234 provides communication links with 
transaction management system 216. as discussed below. 

[0030] In the disclosed embodiment of the invention, computers 124. 144 are IBM AS/400 computers, computer 154 
Is an IBM RS6000, gateway server 126 is an NCR 3410. workstations 128. 1 48 are based on '486 or better processors. 

25 and transaction management system 216. 216' Is AT&Ts TOP END. WAN 102 employs TCP/IP. an open communica- 
tion protocol, while LANs 120 employ an IBM communication protocol. LU6.2. LU6.2 allows direct communication 
between LAN nodes, but it is not the prefen-ed protocol for communications on WAN 102. In the prefen-ed embodiment 
of system 100. LAN/WAN interface 280 includes the software necessary to couple message packets between LU6.2 
and TCP/IP protocols for communications between central LAN 110 and casino property LANs 120. In particular, 

30 LAN/WAN IF 280 operates in conjunction with transaction management system 216. 216* to provide CMS 234, LMS 
238. and EMS 240 with rapid access to customer accounts for ail customers who have visited any casino property affil- 
iated with the casino company and obtained a customer ID card. For this purpose, each customer ID card Includes a 
unique ID number that is associated with a customer account in CPDB 220. 

[0031] In the prefenred embodiment of the Invention, the RPG applications of CMS 234 are implemented in the AS400 

35 environment of computer 124. In order to facilitate fast, real-time communication between CMS 234 and CPDB 220, a 
messaging system is implemented as part of interface module 235 of computer 124 and transaction management sys- 
tem 21 6' of server 1 1 2. The messaging system functions as an application program interface (API) that allows the RPG 
applications of CMS 234 to communicate with CPDB 220 via transaction management system 216, 216\ with 
LAN/W/VN interface 280 coupling messages between the different communications protocols. 

40 [0032] In the preferred embodiment of system 1 00, customer data Is transferred between LAN 120 and LAN 1 10 by 
means of message packets comprising header and data segments, the attributes of which are specified in a data dic- 
tionary associated with the messaging system. The data segments reflect the database schema of CPDB 220 and the 
header segments correspond to user provided service applications (not shown) accessed through trar^ction manage- 
ment system 216. These user provided service applications implement functions for coupling data to and from CPDB 

45 220 in response to requests from CMS 234. A utility associated with the messaging system reads the data dictionary 
and defines data structures in the AS400 system environment suitable for passing data between the RPG applications 
of CMS 234 and the messaging system. A message building/parsing module uses data provided through the defined 
data structures tobuiM message packets for transmitting requests to transaction management system 216, 216*. which 
directs the request to the appropriate service application. A message building/parsing module associated with the serv- 

50 ice applications provides analogous services for communications with DBMS 214. The messaging system is described 
in greater detail below witii respect to Figs. 6-12. 

[0033] As noted above, the optimal architecture for system 100 will be determined in part by the volume of data traffic 
that WAN 102 can handle, i.e. the "bandwidtti" of WAN 102. The embodiment of Figs. 1. 2 A. and 2B. in which each 
casino LAN 120 includes CMS 234 for handling day to day transactions and communicating data to CPDB 220, bal- 
55 ances the advantages of centralized computing systems with the bandwidth limitations of typk:al WANs 102. Where 
VJm 102 has sufficient t>anclwidth to handle real-time data transactions between CPDB 220 and a plurality of casino 
properties, local CMS 234 at each of tiie plurality of casino properties may be eliminated in favor of a centralized CMS 
234 implemented on central LAN 110. 
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[0034] Referring now to Fig. 20, there is shown a simplified block diagram of an alternative, centralized configuration 
for system 100. In the configuration of Fig. 2C, local CMSs 234 associated with selected casino LANs 120' have been 
eliminated in favor of a central CMS 284 supported on sewer 1 16 on central LAN 1 10.ln this embodiment of the inven- 
tion, each casino LAN 120' includes one or more computers 124' for communicating with central CMS 284 over WAN 

5 102. Since computers 124' merely provide access to central CMS 284, they may be workstations or PCs. Central CMS 
284 handles day to day transactions for each of casino LANs 1 20'. maintaining a separate data store for each LAN 1 20' 
under its management. The data stores of central CMS 284 for LANs 120' are periodically updated to CPDB 220 to 
maintain the centralized data cunent. Where the data capacity of WAN 102 is sufficiently, it may be possible to eliminate 
local CMS 234 from all LANs 120. 120'. Similar hybrid and fully centralized configurations may also be set up for LMS 

10 238 and EMS 240. 

[0035] Another alternative to the configurations of Fig. 2A, 2B, and 2C is a fully decentralized configuration In which 
CPDB 220 is eliminated in favor of a distributed database. This configuration Is discussed in greater detail In conjunction 
with Fig. 5. Unless othennnse indicated, the following discussion assumes system 100 Is configured as indicated In Figs. 
2A and 2B. 

15 [0036] Referring now to Fig. 3. there is shown the embodiment of system 100 including CPDB 220 and local CMS 
234, with communications links between different nodes explicitly indicated. In the disclosed embodiment, for example. 
CMS 234 receives customer activity input directly from gaming tables 134, kiosks 136, restaurants or privileged facilities 
133. and a customer information center 1 38. CMS 234 also receives customer activity data from slots 130 through SMS 
262. Kiosks 136 are terminals located round the casino property that allow customers to check on their activity points 

20 or comp availability by inserting their customer ID cards. Customer information center 138 provides services to casino 
patrons such as membership information and arranging for "comps", as described in detail below. CMS 234 also pro- 
vides data to each of these input devices. For example, casino employees at gaming tables 134 receive customer data 
summaries so they can determine whether the customer qualifies for a "comp" or simply greet the customer by name. 
[0037] LMS 238 receives customer data from a hotel desk 1 78 and reservations clerks 176 and provides customer 

25 account summaries to these locations for use by casino enrployees. EMS 240 also exchanges customer data with res- 
ervations clerks 176 and. In addition, exchanges customer data with events venues 1 74. 

[0038] In the disclosed embodiment, both LMS 238 and EMS 240 communicate with gateway server 126 through 
CMS 234, and gateway server 126 handles the data translation necessary to communicate with CPDB 220 via WAN 
102. This communication topology facilitates searching among different management systems 234, 238, 240 for cus- 
30 tomer data, but it Is not essential to the present Invention. The same system could be operated with EMS 240 and LMS 
238 communicating with gateway server 1 26 directly In addition, where UNIX-based casino, lodging, or event manage- 
ment systems are available, they may communicate directly with WAN 102. 

[0039] Also shown in Fig. 3 is a teleservices module 298 coupled to CPDB 220 through WAN 1 02. Teleservices mod- 
ule 298 represents a telephone-based system that allows customers to arrange travel plans at some or ail of the affili- 
35 ated casino properties. By connecting teleservices module 298 to WAN 102. operators can access customer data In 
CPDB 220 in real-time. This allows operators to determine, for example, whether a customer arranging a trip to one of 
the affiliated casino properties qualifies for a comp room, a room upgrade, or the like. 

[0040] Customer accounts In CPDB 220. and in the local datat>ase of the CMS 234, include detailed information on 
the customer's preferences, interests, credit rating, win profiles, and accunrujiated activity points. Each customer 

40 account also includes at least one field for indicating the status of the customer. In one entbodiment the status field may 
indicate a customer's status as special status customer or a non-special status customer. Special status customers 
include for example. "VIP" customers, and memt>ers of exclusive programs or dut^s maintained by the casino. In a pre- 
ferred embodiment, the status field is a Boolean which is used to indicate whether or not the customer is a "Premier" 
guest, a particular type of special status customer. The status of a customer preferably reflects the customer's worth to 

45 the casino, and is determined as a function of the customer's betting activity. In one embodiment, the customer's status 
is a function of the customer's theoretical win value to the casino. In another embodiment, status is a function of total 
accumulated points In the customer's account. In yet another emt^odiment, status is a function of both theoretical win 
and accumulated points. In one ennbodiment. theoretical win values and points are determined according to gaming 
data accumulated at any of the casino properties affiliated with the parent company through input devices such as slot 

so machines 130 and dumb terminals 132 associated with gaming tables 134. In another embodimerrt, theoretical win and 
points are based on gaming data accumulated at a single casino property. Activity points are determined in part by 
gaming activity but may also be augmented by sveepstakes and various other promotional programs. Other customer 
data relating to non-gaming activity may be tracked tiirough various input devices, including wor1<stations 1 28. 148 sup- 
porting EMS 240 and POS 244, and made available to the marketing department for evaluation and analysis. 

55 [0041] In order to provide rapid access to essential customer data while minimizing data storage requirements for 
casino properties, each CMS 234 maintains accounts for regular customers in a local database. With this configuration. 
CMS 234 accesses CPDB 220 whenever a customer registers activity in any of the casino venues and no customer 
account data is available locally. For exanple. when a customer presents his or her identity card to check into tiie hotel 
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at the casino property, LMS 238 checks with CMS 234 for a local customer account. Currently, LMS 238 does not main- 
tain a local data store, but if expanded to do so. LMS 238 would check its local data store before checking that of CMS 

234. 

[0042] In general, customer data may already be available locally from CMS 234 if the customer has visited the casino 

5 property before or if, for instance, a new customer played slot machines 130 before checking in to the hotel. In the first 
case, static customer data, including the customer's name, address, credit rating and the like, would be maintained in 
CMS 234 from the previous visits. In the case of a new customer, CMS 234 will have already retrieved a summary of 
the customer's account data from CPDB 220, as described below, and LMS 238 may access the data from CMS 234. 
[0043] If the customer data is not available locally, as when a customer new to the casino property checks Into the 

10 hotel first. LMS 238 will send a data request to CMS 234. which forwards it to CPDB 220 using the messaging system 
and transaction management system 216, 216*. This transaction is carried out on-line in order to provide rapid access 
to a summary of basic customer information such as the customer's address, credit status, gaming points, theoretical 
win profile, and recent trip activity. Ready access to this customer data allows casino employees to make the check-in 
process both more efficient and more personalized for the customer, enhancing the customer's overall expenence and 

15 making him or her more likely to return. 

[0044] Throughout the customer's stay at the casino property, the customer's account will be updated to reflect the 
customer's activities at the various casino venues. For example, when the customer inserts his or her identity card into 
a card reader 724, such as at slot machine 130 or gaming tak>le 134, the account number is read, the customer's betting 
activity is monitored, and the customer's account updated to reflect the activity, including updating of the customer's sta- 

20 tus. Similarly, if the customer purchases an event ticket or redeems customer activity points for a meal, workstations 
1 18. 148. respectively, provide the ID number and transaction data to CMS 234. which updates the customer account 
to reflect the transaction. LAN 120 thus allows all of the customer's activity at the associated casino property to be 
tracked, which in turn provides a more accurate picture of the customer's value to the casino. 

[0045] The cross-property nature of system 1 00 makes the accumulated customer data available at whichever casino 
25 property the customer decides to visit. In order to maintain all account data up to date, all data processed by local man- 
agement systems CMS 234. LMS 238. and EMS 240 is periodically updated to CPDB server 112 in a batch process. 
This update synchronizes data in all storage locations, i.e. CPDB 220 and local databases associated with CMSs 234. 
to ensure that employees at any casino property have access to the latest data. When this configuration is employed 
with a WAN 102 having limited bandwidth, data synchronization is typically done when traffic on WAN 120 is low. in 
30 order to minimize any interference with on-line data access transmissions. 

[0046] Data must also be synchronized in the configuration of Fig. 2C. with central CMS 234 periodically updating 
CPDB 220 from the data stores associated with LANs 120'. However, data traffic generated by these updates is limited 
to central LAN 120 and does not impact the data traffic on WAN 102. 

[0047] The seamless flow of data supported by the. present invention reinforces the customer's perception of the 

35 national brand associated with the parent company and the activity point system provides additional incentives for the 
customer to patronize the casino's properties in different locations. In the absence of the method of the present inven- 
tion, there Is no record of the customer's activities at other casino properties and. consequently, there is no opportunity 
to leverage the data already accumulated on the customer to affirm the corporate links between the properties. 
[0048] Referring now to Rg. 4. there Is shown a flow chart of method 400 in accordance with the present invention for 

40 tracking customer activity data and accumulating activity points across casino properties. For purposes of illustration, 
the discussion assumes that the customer activity data is being directed to CMS 234. i.e. gaming activity of some sort 
is being tracked. Method 400 is initiated when a triggering event, such as insertion of an ID card Into a slot macfiine 1 30 
or entry of an ID number or name into a dumb terminal 1 32 is detected 410. The customer ID number (or name) is read 
420 by CMS 234. which determines 430 whether it has already activated tiie associated customer account, if the 

45 account has not yet been activated by CMS 234 at the current casino property, the customer account is activated 434 
in CMS 234. a request for summary data from tiie customer's account is forwarded 438 to CPDB 220 and the activated 
account is updated 442 with the summary data from CPDB 220. If, on the other hand, it is determined 430 that an 
account is already activated, the summary data is already available and the customer account is thereafter updated 444 
to reflect any new activity. In either case, tiie status of the customer is also determined 431 . and if the customer is a 

so special status customer, a physical instrumentality proximate the customer is activated 433 for the customer's benefit. 
[0049] It is noted tiiat in the centralized configuration of system 1 00 (Fig. 2C). centi-al CMS 284 maintains data stores 
for each LAN 120 it handles. Consequently, the checking process described above occurs with centralized CMS 284 as 
well. 

[0050] Gaming and non-gaming activities are treated differentiy, and updates occumng at step 444 typically include 
55 non-wagering activities related to gaming. For example, a customer's account may be updated at tNs point to reflect 
redemption of activity points, redenption of a comp voucher, or currency or marker transaction (credit advance). In 
addition, some wagering related data may be updated 444 at tiiis time. For example, tiie start time of a betting session 
or the venue at which a wagering activity is occurring may be reflected to the customer's account 
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[0051] As noted above, activity point awards are based on a number of criteria and these may be adjusted to target 
different casino properties or venues. In addition, the number of points awarded for an activity may be a function of the 
status of the customer as determined at step 431 . At step 448. method 400 determines whether the monitored activity 
is one for which any points are awarded. In the preferred embodiment of the invention, non-gaming activity, such as 
5 hotel and event activity, may be tracked for accounting and marketing purposes. Once non-gaming activity has been 
reflected in the customer account, method 400 returns to await 410 the next triggering event. 

[0052] In the current embodiment of the invention, points are awarded for gaming activities, but this may be readily 
expanded to include point awards for non-gaming activities. With respect to gaming activities, points awards are deter- 
mined when the activities are completed or an account status is requested. For example, when a customer initially 

10 inserts an identity card into a slot machine 130, method 400 will be triggered 410 to record the event. However, the 
activity points awarded are based in part on how much the customer wagers, and this is not determined until the cus- 
tomer removes his or her card from the slot machine 130 or an update request is received by SMS 262. If the current 
triggering event is. for example, a card removal or status request, the customer account is updated 450. Otherwise, 
method 400 returns to step 410 to await the next triggering event. For this reason, SMS 262 (Fig, 1 . 2B) maintains bet- 

;5 ting data until one of these events ti-igger it to forward the data to CMS 234 for updating the appropriate customer 
account. 

[0053] Referring again to Fig. 4. points are updated 450 when a betting session is completed or an account status 
requested, and method 400 checks 452 a table to determine the number of points to be awarded. For example, the 
company may promote a new casino property by awarding bonus points for all gaming activities at the new property, or 

CO the casino may award bonus points for gaming at a new venue that is being promoted. In any case, method 400 deter- 
mines 452 the appropriate point level and adjusts 454 the point tally in the customer's account accordingly. 
[0054] Betting activity is also reflected 458 in a separate field for purposes of determining a customer*s comps. Unlike 
activity points, comp data is based solely on the historical amount of wagering done by the customer and does not 
reflect point weighting or other promotional schemes. When any point and comp adjustments have been made, method 

25 400 returns to await 410 the next triggering event. 

[0055] CPDB updates 460 are required to synchronize data in the embodiment of system 100 employing distributed 
CMSs 234 and centralized CMS 284 (Figs. 2A and 2B, and Fig. 2C. respectively). In the former configuration, these 
updates periodically transfer accumulated data from all accounts in local management systems (typically, CMS 234) to 
CPDB 220. In the preferred embodiment of this configuration, updates to CPDB 220 are scheduled at least once every 

30 twenty four hours at time periods when activities on casino LANs 120. central LAN 1 10, and WAN 102 are low. Where 
WAN 1 02 has a high bandwidtii. data updates may be made without regard to other ti-affic on WAN 102. For the reasons 
discussed above, CPDB updates from the data store of central CMS 284 do not impact data traffic on WAN 102 and 
may be scheduled more flexibly. 

[0056] Method 400 balances the casino company's need for rapid on-line access to customer information from all of 
35 its casino properties with the personnel and monetary costs of maintaining multiple large databases. Instead of dupli- 
cating all customer accounts at all casino properties, copies of a customer's account are maintained only on central 
database sewer 112 and in databases of CMS 234. CMS 284 associated with those casino properties visited by the 
customer. On the other hand, the data is available from central database sewer 1 1 2 whenever it is requested by another 
casino property. In the preferred embodiment of the invention, static customer data is maintained on local CMS 234 for 
40 a period of between six nrK>nths and two years, depending on each casino's policy If no activity is registered by a cus- 
tomer during tinis period, the local account may be purged. 

[0057] Computer system 1 00 and method 400 provide tiie infrastructure for a national customer recognition program 
for attracting and retaining customers. They also provide the raw customer data on which the casino company can base 
its marketing decisions and through which the company can launch new marketing programs. 

45 [0058] Customer recognition awards may be based on different subsets of customer data accumulated through and 
stored on system 100. The customer recognition program based on activity points has already k>een mentioned. A cus- 
tomer accumulates points in his or her customer account according to his or her activity at all venues of all casino prop- 
erties and according to any promotions currently being run by the casino or its parent company. The accumulated points 
represent a monetary value associated with the customer's activities and may be used in place of cash within any of tiie 

so affiliated casinos. Thus, in addition to tiie already noted benefits of the point system, it contributes to the establishment 
of a cashless, paperless business environment. 

[0059] In order to provide an incentive for customers to accumulate points, points may be earned at any casino prop- 
erty affiliated with the company. The aoss-property nature of point accumulation encourages customers to visit casino 
properties affiliated with the parent company when they travel, since this activity contributes to their rewards no matter 
55 which casino property is the source of the points. Point awards may be structured in a variety of ways to target specific 
activities. For example, bonus points may be awarded to customers who visit at least two affiliated caano properties 
within a given time period. Point awards may also be based on a tiered system, under which customers accumulate 
points for their gaming activities at rates that increase as their point totals increase. In general, point awards may be 
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instituted for different time pericxJs and for different properties, according to the marketing goals of the casino and the 
parent company. 

[0060] Accumulated points may also be redeemed at any casino property affiliated with the casino company Using 
system 100. a casino employee can call up data indicating the accumulated points of any casino customer, regardless 
5 of the property at which the points were earned and regardless of whether the customer is a regular at the casino prop- 
erty. For example, a customer who has been accumulating points through regular visits to a Las Vegas casino can visit 
an affiliated casino in New Jersey and redeem his or her accumulated points for goods or services at the New Jersey 
casino. 

[0061 ] Point awards also encourage customers to use their ID numbers at any of casino venues of the affiliated casino 
70 properties that offer customer tracking. This enhances customers' interest in participating in tracking programs and pro- 
vides the casino company with more data on which to base its marketing decisions. Thus, the point system can be used 
to both recognize customers for their patronage and to market different facilities of the company 
[0062] Comping is another customer recognition program that is supported by system 100 and method 400. Comps 
are awarded to a customer according to the customer's average dally theoretical win. which is an estimate of the 
15 casino's average daily winnings from the customer. The level of conrps available to a customer is based on the casino's 
theoretical win from different gambling activities and the customer's historic level of these gambling activities. For exam- 
ple, on average a casino will win a statistically determinable amount of money, i.e. the theoretical win, from a customer 
who bets an average of $5000 per trip on bladqack. If the customer's theoretical win profile is large enough, the casino 
may "comp" the customer a free night's lodging, allowing the customer an additional day of gaming. Customer betting 
20 activity accumulated by system 100 is crucial to comping customers at a level commensurate with their expenditures, 
since it provides the raw data on the customer's betting activity. 

[0063] Casino employees have some discretion in awarding comps and the practice may vary from one casino prop- 
erty to another. System 100 helps eliminate some of the vagaries introduced by the discretionary nature of comping by 
providing the same customer data to employees at all casino properties visited by a customer. This ensures that comp- 
os ing decisions will at least be based on consistent estimates of the customer's average theoretical win profile. Regular 
customers at one casino property of the company who visit a new casino property of the company are more likely to be 
"comped" at a level consistent with their play at their regular casino property. The national character of the present 
tracking system also means that the average daily wager figure will include a larger number of data points, since the 
customer's gaming activities at alt casino properties are included. Estimates based on this data should be that much 
30 more accurate. 

[0064] Customer data accumulated by system 100 is also used in tracking customer offers to determine the validity 
of outstanding offers and the profitability of those offers for the casino. These offers can be entered into a customer's 
account to indicate their availability to the customer, and the customer's account can be updated as necessary when 
an offer is redeemed. In addition, data accumulated in CPDB 220 during the visit in which the customer redeems the 

35 offer can be used to determine whether or not it is profitable for the casino to repeat the offer or make additional offers. 
For example, the casino may send to selected customers offers for a free nights lodging at one of its properties if the 
customer stays for at least two nights. In certain cases, the customer's incremental expenditures for the extra day's stay 
may not justify repeating the offer to that customer. Information gathered on customer activity associated with an offer 
may also allow the marketing department to better target their offers. 

40 [0065] Referring now to Fig. 5, there is shown a simplified Ijlock diagram of an alternative embodiment of system 100. 
in which both management system processing and database operations are distributed among LANs 120. This emkxxJ- 
iment Is illustrated using four LANs 120(1)-120(4) coupled to WAN 102. but the number of LANs 120 may be greater or 
less than this. 

[0066] LANs 120{1)-120(4) include local CMS 234(1 )-234(4). respectively, each of which has an associated local 
45 database. The local databases of CMS 234( 1 ) - 234(4) form the distributed database for this embodiment of the present 
invention. Each local database comprises a local guest master list for the corresponding casino property and a local 
cross-reference list that includes selected customer data from every other affiliated casino property. For example, the 
local guest master list of CMS 234(1) comprises data for all casino customers who received their Identity cards at the 
associated casino property (property 1). The local cross-reference list of CMS 234(1) includes data sections for prop- 
so erties 2. 3, and 4. which comprise customer data for any customer that received their Identity card at property 2, 3, or 
4, respectively, arxi subsequently visited property 1 . CMS 234(1) also Includes virtual files 2. 3. and 4 for properties 2. 
3, and 4. respectively, through which data on customers who are not listed in either the local master list or local cross- 
reference list may be accessed. In effect, virtual files 2, 3. 4 on CMS 234(1) represent local master lists residing on CMS 
234(2). CMS 234(3). and CMS 234(4), respectively, that are accessed by CMS 234(1) through WAN 102. 
55 [0067] In this embodiment of the invention, a customer of a casino is assigned an identification number including a 
property field that indicates the casino at which the customer's account originated, i.e. where the card was Issued. 
When a customer of property 1 uses his or her card at property 1 , the property field indicates to CMS 234(1) that the 
customer's account data is accessa)le tiirough the local master list of C^S 234(1). On the other hand, when this cus- 
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tomer visits property 3. the property field signals that CMS 234(3) should check the data segment associated with prop- 
erty 1 in the local cross-reference list for the customer's account. If it is the customer's first visit to property 3. there will 
be no account data In the property 1 data segment of the local cross-reference list and CMS 234(3) will use virtual file 
1 to access the local master list of CMS 234(1). When the data is retrieved from CMS 234(1), it is stored In the property 
5 1 data segment of the local cross-reference list of CMS 234(3). where it is updated with the customer's activity during 
his or her visit to property 3. 

[0068] In the system of Fig. 5. where a distributed database configuration is employed, data synchronization is par- 
ticularly important to ensure that all activity data, including points and comp availability, is reflected in a customer's 
account and is available at any of the affiliated casino properties. For example, when a customer from property 1 visits 

10 property 3. the data on the customer's activity at property 3 is added to his or her account in the property 1 segment of 
the local cross reference list of CMS 234(3). Data synchronization ensures that this new data, including points or comps 
that are earned or redeemed during tiie visit, is available when the customer visits any other property Synchronization 
may be accomplished in a number of ways. For example, the customer's accounts at each casino property may be peri- 
odically updated to reflect any activity recorded by the customer at any of the affiliated properties, so that each property 

75 visited by the customer has a complete set of the latest data. 

[0069] Alternatively, all changes to a customer's account on any guest master list may be periodically updated to the 
customer's principal account, i.e. the account at the Issuing property In this case, each visit to a different property 
requires updating of the customer account on the guest master list with the account data from the customer's principal 
account. Provided these or similar procedures are implemented to ensure the coherency of the distributed database. 

20 the point and comp system may be implemented in the manner described above. 

[0070] The present invention provides for the activation of various physical instrimientalities in response to recogniz- 
ing the customer and determining the customer status encoded in tiie customer account. Refen-ing now to Fig. 13. there 
is shown an illustration of a gaming machine configuration 600 including exemplary physical instrumentalities that may 
be activated when a customer is recognized and the customer's status determined. One embodiment of the gaming 

25 machine configuration 600 includes a slot machine 1 30 that rests on cabinet 604. The slot machine 1 30 has a light 602 
mounted at its top. which provide a highly visible, and selectively activateable lighted display The cabinet 604 includes 
lockable interior compartment 614 with a solenoid-controlled lock 615 in the door thereof. When engaged, the solenoid 
(not shown) engages the lock 61 5 in a locked position so that the door to tiie compartment 61 4 cannot be opened, and 
the lock 61 5 cannot be used. When disengaged, the lock 61 5 is released and the door to the compartment 61 4 may be 

30 opened or closed: the lock 615 may then be used to manually lock the door to secure the compartment 614. In other 
embodiments, slot machine 130 is replaced by other gaming machines, for example any of the numerous varieties of 
video or computer-based poker, slots, keno, gaming machines. Alternatively, the cabinet 604 (or a suitably structured 
variant thereof) may be provided in conjunction with a gaming table 134, such as part of a blacl^ack or other card table. 
[0071] In the illustrated embodiment, a backboard 610 extends from the back of the cabinet 604 and includes a tele- 

35 phone mounting plate 608 with a standard RJ-1 1 telephone line jack (not shown). The mounting plate 608 receives a 
telephone 609 and couples it to a telephone line via the line jack. The telephone line jack is selectively activateable to 
allow selected customers to use the telephone 609. 

[0072] Referring to Fig. 14 there is shown a block diagram of the gaming machine configuration 600 in accordance 
with the present invention. The gaming machine configuration 600 includes within tiie slot machine 130 a main process- 

40 ing unit (MPU) 702, a game monitoring unit (QMU) 708, and direct drive relay board 714. The GMU 708 is a Bally Sys- 
tems, Inc. computer board that communicates with the SMS 262. In particular, the GMU 708 communicates betting data 
of the customer to the SMS 262, and receives from the SMS 262 message data pertaining to the customer, such as 
customer status information from the customer's account in the CPDB 220 or in the CMS 234 local database. The MPU 
702 controls the overall functionality of the slot machine 602. The MPU 702 communicates witii the GMU 708 via a con- 

45 nection between a communications port 706 and a plug in card 71 2. The GMU 708 includes direct drive plug in 71 0 tiiat 
couples to the direct drive relay board 714. The GMU 708 and MPU 702 are also coupled to a card reader 724 which 
reads an inserted customer identity card. 

[0073] The direct drive relay board 714 contains a number of relays 71 6, each of which controls a physical instrumen- 
tality proximate to the gaming machine configuration 600. In the illustrated embodiment, relay 716b is coupled to tiie 
so light 606, relay 716c is coupled to the solenoid 720 that ccrrtrols the lock 615 for the interior compartment, and relay 
71 6d is coupled to the line jack 623. The direct drive relay board 714 also includes logic to control the various relays 
716 in response to control signals from the GMU 708. 

[0074] In accordance with the present invention, the gaining machine configuration 600 operates as follows to provide 
customer wortii differentiation. When a customer inserts his or her identity card into card reader 724. tiie SMS 262 
55 sends a message containing customer data, including status data from the customer's account in the CPDB 220 or 
from a local database. This message is read by the GMU 708. If status data indicates a special status customer, the 
GMU 708 sends an activate signal to the direct drive relay board 714. The direct drive relay board 714 activates a des- 
ignated relay 716 to activate one or more of the physical instrumentalities coupled to the relays 716. 
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[0075] In a simple embodiment, where there is only a single type of special status customer, all employed relays 716 
are signaled to activate their respective physical instrumentalities. In this embodiment, relay 71 6b is activated and ener- 
gizes the light 602 on top o1 the slot machine 130. This alerts both casino personnel and other customers of the special 
status of the customer at the slot machine 130. Alerting casino personnel also allows these personnel to provide better 
5 service to the special customer, such as faster or more frequent food and beverage service, or faster slot changes. 
[0076] Also, relay 71 6c is activated, which controls solenoid 720. releasing the lock 61 5. The special status customer 
is now able to use the interior compartment 61 4. and manually lock it and unlock it with a casino-supplied key This ena- 
bles the special customer to privately and securely store personal belongings at the slot machine 130, without fear of 
loss. 

10 [0077] Relay 71 6d is also activated, coupling the line jack 623 to the telephone line, and thereby activating telephone 
609 for use by the customer. These various physical instrumentalities provide an enhanced experience to the special 
status customer, and thereby increase the customer's sense of brand loyalty to the casino. In addition, these activated 
physical instrumentalities allow the casino to differentiate between customers based on their worth to the casino. 
[0078] In another embodiment where there are multiple categories of special status customers, then individual ones 

15 of the physical instrumentalities may be activated depending on the particular type of special customer. For example, a 
first type of special status customer may only have light 602 activated. A second type of special customer may have 
both the light 602 activated and the lock 615 to the interior compartment 614 enabled. Finally, a third type of special 
customer may also have the telephone 609 also activated in conjunction with the light 602 and lock 615. In another 
alternate embodiment, activation of selected ones of the physical instrumentalities may be based on the customer's 

20 point total in customer account, so that as higher point totals are reached, additional physical Instrumentalities that 
enhance the customer's experience are activated. 

[0079] The physical instrumentalities described with respect to Figs. 1 3 and 1 4 are merely exemplary of a wide range 
of physical instrumentalities that may be activated on the basis of recognition of special status customers. The present 
invention entails the selective activation of physical instrumentalities at any location in or about the casino in response 
25 to Status data indicating the status of a customer. Exemplary structural features to provide for identification of special 
status customers include a card reader 724, a control mechanism such as direct drive relay board 714, and a logic unit 
such as a GMU 708 that may be installed to control activation of the physical instrumentality These structural features 
would be coupled to a LAN 120. a CMS 234 or the like, and a CPDB 220. for example as described with respect to Fig. 
2B. 

30 [0080] For example, the casino may have privileged facilities, such as member-only dubs, that are accessed by con- 
trolled doors, with any variety of computer-controllable locking mechanisms. The locking mechanism of such a door 
may be coupled to a relay 71 6 and a logic unit, which in turn are coupled to a card reader 724 located suitably near the 
controlled door. Insertion of the customer identity card initiates communication with the CMS 234 to obtain customer 
data Including status data from the CPDB 220. If the customer status data Indicates a special customer, the logic unit 

35 signals the controllable locking mechanism to unlock the doors and allow access to the privileged facility 

[0081] In another embodiment of the present invention, distinguished services may be provided to the special status 
customer in conjunction with the activation of physical instrumentalities. The variety of distinguished services will gen- 
erally depend on the location of the customer in the casino property at the time the customer is recognized as a special 
status customer. A distinguished service is a service that is preferably provided only to special status customers and 

40 serves to enhance the customer's experience at the casino property. 

[0082] In one emtKxJiment, the distinguished services are provided to a customer at gaming machines, such as slot 
machines 130. gaming tables 134. and the like following recognition of the customer as a special status customer. For 
a customer at a gaming machine or gaming table 1 34, distinguished services include faster slot change to the customer, 
faster slot fills, and fast©- slot payouts, as compared to how these services are provided to non-special status custom- 

45 ers. Other distinguished services include express or more frequent food or beverage service to the customer at the 
gaming machine or gaming table. One means by which these distinguished services are initiated is by a light 602 situ- 
ated proximate the gaming machine. When the light 602 is activated upon identification of a special status customer, 
casino personnel who see the light 602. are immediately aware of the presence of the special status customer at the 
particular gaming machine having the light 602. Accordingly, these casino personnel can provide the distinguished 

so services to the customer as needed. 

[0083] In other embodiments, distinguished services are provided to a customer who patronizes dining or entertain- 
ment facilities at the casino property. In these enr*>odiments, card readers 724 are placed near the entrance to these 
facilities, and are coupled to the LAN 120. and CPDB 220 as described above. When the customer approaches the 
facilities, he inserts his identity card into the card reader 724. In the manner desaibed above, the CMS 234 obtains the 

55 customer*s account data from the CDPB 220 and determines the status of the customer. Where the customer is a spe- 
cial status customer, the customer is provided with a relevant (fistinguished service at the facility. For example, distin- 
guished services in this context include priority or prefened seating at the facility. Casino personnel at the facility may 
be apprised of the presence of the special status customer by activation of indicators on terminals 132 or computers 
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1 72 located at the facility. 

[0084] There has thus been disclosed a system and method for collecting customer data across all of the casino prop- 
erties of a company, accumulating the collected data in a patron database, and making the accumulated data available 
at any casino property when triggered by a customer visit to the casino property. The system provides an infrastructure 

5 for implementing across all affiliated casino properties a point system that rewards customers for the gaming activities 
and allows targeting of different casino properties and venues for marketing purposes. The system also makes availa- 
ble to casino employees the same customer data, independent of which casino property the customer visits regularly. 
This allows customers to receive personalized service and to be rewarded in accordance with their value to the casino 
even when visiting new casino properties. 

10 [0085] Referring generally now to Figs. 6-12 there is shown an embodiment of the messaging system employed in 
the preferred embodiment of computer system 100 (Fig. 1). 

[0086] Referring first to Fig. 6. there is shown a block diagram of a networked computer system A100 that includes a 
messaging system A120 for communications between application programs on proprietary and open system platforms. 
Computer system A100 comprises a first computer A1 12 based on a proprietary system architecture, a server A192 

75 based on an open system architecture, and a gateway server A152 for connecting the different system architectures. 
The proprietary system architecture of first computer A11 2 is represented by network protocol A1 30, and the open sys- 
tem architecture of server A1 92 is represented by network protocol A160. In the disclosed embodiment of system A1 00. 
the open system architecture is UNIX. Windows, or the like, the network protocol A1 60 is TCP/IP, the proprietary system 
architecture is IBM's System Network Architecture (SNA), and network protocol A130 is IBM's SNA LU6.2 

20 [0087] First computer A1 1 2 includes an RPG application A1 1 0, messaging system A1 20. and network protocol A1 30. 
Messaging system A1 20 acts as an application program Interface (API) between RPG application A1 1 0 and a transac- 
tion management system A150 on gateway server 152. Transaction management system 150, in turn, provides access 
to transaction services A170 on open system server 192. Transaction services 170 represents the different services 
that may be accessed by RPG application A1 10 and the means for accessing these services. 

25 [0088] Gateway server A152 includes a network services module A140, transaction management system A150, and 
an interface module A1 42. When triggered by messaging system A1 20. network service module A1 40 allocates a con- 
versation between messaging system A120 and transaction management system A150 by means of interface module 
A142. A conversation is a logical connection that allows communications betvyeen applications on different nodes to 
proceed, while hiding the details of the underlying communication protocol from the communicating applications. In the 

30 disclosed embodiment, the allocated conversation carries message packets between messaging system A120 and 
transaction management system A150 using network protocol 130. The communication link between RPG application 
A1 10 and transaction services A170 is completed by a dialogue between transaction management system A150 and 
transaction services A170 based on network protocol 160. The message packets generated by messaging system 
A120 include parameters, i.e. data and control information, necessary to activate one of transaction services A170. 

35 carry on communications with the activated service, and terminate it. 

[0089] Referring now to Fig. 8. there is a block diagram of a transaction service A1 70, which comprises an instance 
of transaction management system A150, including a client-server interface (CSI) A154, a service application A310, a 
message conversion system A304, and a database management system (DBMS) A380. Service application A3 10 is a 
user provided module that includes functions for accessing data from DB A390 through DBMS A280. In the disclosed 

40 embodiment. DBMS A380 is Informix 7.0. and transaction management system A150 is AT&Ts TOP END. both of 
which conform to the X/Open distributed transaction processing (DTP) XA Interface. Transaction management system 
A150 also conforms to the DTP TX interface for communications with service application A3 10. 
[0090] Referring now to Fig. 7, there is shown a block diagram of messaging system A1 20 comprising a MSG module 
A210. a MSG Build/Parse module A220, a List_Build module A230. a memory management module A240. an 

45 Inbound/outbound message buffer A218. and defined data structures A250 for coupling data between messaging sys- 
tem A120 and RPG application A110. In order to make messaging system A120 portable between platforms, compo- 
nent modules A210, A220. A230, and A240 are written in C programming language. 

[0091] MSG module A210 Includes a MSG API A212 through which RPG application A1 10 accesses functions A214 
for initiating and terminating conversations with transaction management system A150 and for requesting transaction 
so processing services from server applications A310 accessed through transaction management system A150. In the 
disclosed embodiment. MSG module A210 also includes registered functions A216, which manipulate data between 
defined data structures A250 and MSG buffer A218 as described below. 

[0092] Build/Parse module A220 comprises a Build/Parse API A222. a data dictionary (DD) A228. message build- 
ing/parsing functions A224, and a registered function (RF) API A226. Buiki/Parse API A222 provides MSG module 
55 A21 0 with access to platform independent message building/parsing functions A224. DD A228 specifies the fields and 
field attributes of data segments that are recognized by an open system resource being accessed by RPG application 
A1 1 0. As discussed in greater detail below. DD A228 contributes to the flexibility of messaging system A1 20. by provid- 
ing a mechanism for altering its message building capabilities without requiring recoding of RPG application A1 10 or 
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server applications A3 10. 

[0093] RF API A226 provides Parse/build module A220 with access to registered functions A216, which manipulate 
RPG data in defined data structures A250. Registered functions A216 are specific to the data types of a platform, and 
including registered functions A216 in MSG module A210 removes any platform<lependence from Build/Parse module 
A220. For example, a substantially identical build/parse module A322 (Fig. 1 1) is employed by server application A310 
on the open system platform. Build/Pane module A320 parses request message packets from RPG application A110 
and builds response message packets to RPG application A110. 

[0094] List^build module A230 and MMS module A240 provides linked list building and memory allocation functions, 
respectively, for MSG module A210 and Build/Parse module A220. For example, when RPG application A1 10 is initial- 
ized, it identifies to MSG module A210 all defined data structures it employs. MSG module A21 0 checks that the defined 
data structures have the proper number of parameters and calls Ust__build module A230 to generate a linked list of 
pointers to the defined data structures. List_build module calls on MMS module A240 as needed to allocate memory for 
the linked list. List^build module A230 and MMS module A240 are also used by MSG module A210 to eliminate the 
linked list when RPG application A1 10 is terminated. 

[0095] Typical service applications A3 1 0 provide RPG application A11 0 with functions for searching and writing data 
to database A390 (Rg. 8). In order for RPG application A1 10 to communicate with database A390, messaging system 
A120 must employ in its data packets, data having attributes consistent with the columns of database A390. Since RPG 
application A1 10 is the ultimate source of data, messaging system A120 must include some means of ensuring con- 
sistency between the attributes of the data segments employed by RPG application A1 1 0 and those of database A390. 
This is the function of defined data structures A250 and DDs A228. A328. 

[0096] Messaging system A120 provides utilities for generating DD A228 and DD A328 (Fig. 11) and defined data 
structures A250 from a single source that includes attribute definitions consistent with those of database A390. This 
ensures that messaging system A1 20 and service application A31 0 support the same vocabulary, which in turn ensures 
that RPG application A11 0 and database A390 can communicate. The single source from which DDs A238. A328 and 
defined data structures A250 are generated is ASCII definition file (ADF) A260. 

[0097] Referring now to Fig. 9, there is shown a block diagram indicating the relationship among ADF A260, DDs 
A228. A328. and defined data structures A250. ADF A260 is a human-readable file that includes descriptions of the 
attributes of every field of every data segment in the system. As noted above, the attributes of a segment correspond 
to the columns (attrilxites) of the database A390. ADF A260 also includes a header segments, which are used to indi- 
cate which service application A310 is being requested by RPG application A110. Header segments include control 
information for error codes and messages, and those header segments associated with service applications A310 that 
require data input from RPG application A1 10, have appended the data segments con-esponding to the required data. 
ADF A260 also includes a list of restricted segments, which are segments that may only be used by selected service 
applications A310. ADF A260 is typically generated through a GUI design tool, which in the preferred embodiment of 
the invention, is Visual Builder Tool (VBT). In essence, ADF A260 specifies the vocabulary understood by database 
A3 90 

[0098] Also shown in Fig. 9 is a Data_Struclure Utility (DSU) A270 which is used to generate defined data structures 
A250 from ADF A260 whenever ADF A260 has been modified. In particular. DSU A270 reads ADF A260 and uses 
Ust_Build module A230 to generate a linked list of fields and a linked list of segments from the entries in ADF A260. 
For every segment in the segment linked list. DSU A270 retrieves attributes of the component fields from the field linked 
list and writes the information to a DDS A250. Defined data structures A250 are then written to a file, which is linked to 
RPG application A110 and messaging system A120 as an externally defined data structure. 

[0099] There are two defined data structures for each data segment defined in ADF A260. Application request data 
stojctures (ARDS) A252 are loaded with data by RPG application A1 10 to provide messaging system A120 with the 
data it needs to a build a message to a service application A310. Application response data structures (ASDS) A254 
are written by messaging system A120 to communicate a response from service application A3 10 to RPG application 
A1 10. following parsing by Build/Parse module A220. A single application control data structure (ACDS) A256 is used 
by RPG application A1 10 to communicate service application requests to messaging system A120. 
[0100] Also shown in Fig. 9 is a utility, DDBIN A280, that reads ADF A260 and generates DD A228 as a binary file 
sorted by segment names. DDBIN A280 also creates a summary information field for DD A228. including the total 
number of segments, offsets into DD A228 for alphabetically sorted segments groups, and an offset into the file for a 
restricted segment file (RSF). DD A228 may be linked into BuiW/Parse module A220 as an include file. Alternatively, the 
contents of DD A228 may be read into a segment cache A325 (Fig. 1 1) associated with Build/Parse module A220. as 
needed, to fadlrtate access to segment information. This latter alternative is employed in messaging conversion module 
A304 (Fig. 8) which is used for message packet buiWing/parsing by service application A310. 

[0101] Referring now to Fig. 10, there is shown a representation of an ACDS A256 that is used by RPG A1 10 to 
request services of messaging systan A120. ACDS A256 is also used by messaging system A120 to provide informa- 
tion on the status off requested services to RPG application A110. A single ACDS A256 is used by RPG applteation 
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A1 10 to indicate which of transaction services A160 is being requested. Details of the requested service are provided 
in the following fields of ACDS A256: (1) Request Service Name, (2) Sending Segments, and (3) Hold Cpntext Flag. 
[0102] Request Service Mame is afield in which the name of a service application A310 available through transaction 
management system A150 is specified. A corresponding header segment defined in ADF A260 is used by messaging 

5 system A120 to indicate to transaction management system A1 50 the type of service being requested. As noted above, 
some service applications A310 require that RPG application A110 provide data along with the service request. In 
these cases, the Sending Segments field is used by RPG application to specify which ARDs A252. if any, contain the 
required data. Each such ARDS A252 is specified in the Sending Segments field by the Segment Name of the data it 
contains, In the preferred embodiment of the invention, the name of each data segment to be sent is concatenated and 

10 delimited by a pipe ( T)- Fox example, where data from three ARDs A252 corresponding to a name (NAT^E), business 
address (BUS), and home address (HOME) will be sent to service application A31 0 specified by ACDS A256. the Send- 
ing Segments field will be NAME|BUS|HOME. Data provided in response to a service request is sent from service appli- 
cation A3 10 to messaging system A120 as data segments. Messaging system A120 makes any necessary data 
conversions and forwards the convened data segments to RPG application A110 using the corresponding ASDSs 

15 A254. 

[0103] Hold Context Flag is set when RPG application A110 will retain an on-going conversation with a service appli- 
cation A310 as, for example, when RPG application A110 will submit sequential service calls to service application 
A310. 

[0104] The Results Services fields of ACDS A256 comprises Return Status Code. Initialized Flag, and Control Flag 
20 fields. Messaging system A120 uses these to indicate to RPG application A1 10 the status of a service request. Return 
Status Code is zero, unless an error has occurred in the Service Request. Initialized Flag is set when messaging sys- 
tem A120 is properly initialized and is zero othenA/ise. Control Flag indicates the status of messaging system A120. It 
is zero by default, four when a service application A3 10 is currently holding context, and some non-zero value other 
than four when a failure occurs in messaging system A120. 
25 [0105] The interactions between RPG application A1 10 and messaging system A120 will now be described from ini- 
tialization through termination of RPG application A110. As noted above, messaging system A120 is initialized through 
a function call from RPG application A1 10 during its initialization. The initializing function call includes a parameter list 
specifying the segment name, segment address, and number of occurrences of each ARDS A252 and ASDS A254 
used by RPG application A1 10 to send data to and receive data from MSG module A210. The parameter list also spec- 
30 if ies the name and address of ACDS A256 used by RPG application A1 1 0 to communicate control information to MSG 
module A210. Addresses for ARDS A252, ASDS A254. and ACDS A256 (collectively, DDSs A250) are in shared mem- 
ory location All 4. 

[0106] On initialization. MSG module A21 0 first checks that DDs A250 are specified properly (3 parameters for each 
ARDS A252 and ASDS A254 and 2 parameters for ACDS A256). MSG module A210 then calls initializing functions in 

35 Build/Parse module A220, IJst_build module A230, and MMS module A240. initializes a conversation with transaction 
management system A150 via network services A140 and IF A142, and waits for a verification message that the con- 
versation has been established. At this time, transaction management system A150 establishes a dialogue with trans- 
action services A160 on open system server A192. MSG module A210 then calls List_build module A230 to generate 
a linked list of pointers to DDSs A250. and List.Build module A230 calls MMS module A240 as needed to allocate 

40 memory for the linked list. 

[0107] Once conversation/dialogue links have been established between messaging system A120 and transaction 
management system A150. RPG application A1 10 accesses a requested sen^ice application A310 of transaction serv- 
ices A160 through transaction management system A150, using messaging system A120 as an application program 
interface (API). RPG application A1 10 initiates a request for services by loading the Request Service Name and Send- 

45 ing Segments List fields of ACDS A256 with the segment name of the service being requested and the segment names 
of any data being sent to the requested service. RPG application A110 also loads each ARDS A252 named on the 
Sending Segments List with the data to be sent. 

[0108] When ARDSs A252 and ACDS A256 are loaded, RPG application A1 10 calls the request function in MSG 
module A210, including the names of ACDS A256 and ARDS A252 in a parameter list associated with the function call. 

so MSG module A210 use the request function to clear the Results Services fields of ACDS A256 and read the Request 
Service Names and Sending Segments List fields of ACDS A256. MSG module A210 writes a control/status header 
(see below) to message buffer A1 18. specifying Request Service Name, a user identification (userid), and status data 
for transaction management system A150. MSG module A210 also calls the Build MSG function in Build/Parse module 
A220 with the parameter list specifying the names of the data segments and the location of the message buffer A218. 

55 [01 09] Build/Parse module A220 handles the conversion and manipulation of data between the DDSs A250 identified 
in the parameter list and message buffer A218. As noted above, the Build/Parse MSG functions of module A220 use 
registered functions A216 to accomplish the actual data manipulation between DDSs A250 and message buffer A218. 
For outbound messages, the Build MSG function uses DD A228 to determine the required form for each segment to be 
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included in the message packet and makes the necessary format conversions. DD A228 is also used on inbound mes- 
sage packets to convert data to a format appropriate to the operating system of the AS/400. The addresses of DDSs 

A250 are determined from the link list generated on initialization. 

[01 1 0] The message packet generated by messaging system A1 20 has the following form: 

(I) I error | control | function code | userid | data |. 

4 control/status ► 1 < application data ► 



10 

The header, comprising error, control, function code, and userid fields, provides the routing and status Information nec- 
essary to transfer the service request and associated data of RPG application A1 10 from messaging system A120 to 
requested service application A3 10. In particular, the error field includes error codes for tracking purposes, the control 
field specifies the status of communications with transaction management system A150. the function code field speci- 
15 fles which service application A310 is being requested, and for security checking purposes, userid identifies the per- 
son(s) using RPG application A110. The data field comprises the service name and any application data, suitably 
formatted, that is being transferred between RPG application A1 10 and service application A310. As discussed above, 
this data is loaded by messaging system A120 using Parse/Build nxxlule A220. 

[0111] Once the message packet has been completed, MSG module A210 calls a send/receive function to fonward 
20 message packet to transaction management system A150 in gateway server A152. using the conversation allocated on 
initialization. Interface module A142 maps the conversation to the dialogue established between transaction manage- 
ment system A1 50 and transaction services A1 60, determines from the function code in the header of message packet 
(I) which service application A31 0 is targeted, and uses transaction management system A150 to call targeted service 
application A3 10. 

25 [01 1 2] Referring now to Fig. 1 1 . there is shown a detailed block diagram of message conversion module A304 com- 
prising a message build/parse module A320, a list_build module A330, and a memory management system (MMS) 
module A340, which perform functions for the open system platform of server A192 that build/parse module A220. 
Iist_build module A230, and MMS module A240 perform on the proprietary platform of AS/400 A112. In the case of 
server A192. however, transaction management system A150 operates in conjunction with CSI A154 to handle routing 

30 and control information. In particular, these components ensure that the data portion off message packet (I) is routed to 
service application A310. Consequently, these is no need for a counterpart of MSG module A210 on server A192. On 
the other hand, the data portion of message packet (I) must be convened into a format suitable for the open system plat- 
form, and this is the function performed by modules A320, A330. A340. 

[0113] As indicated in Fig. 1 1 . service application A310 has associated registered functions A316 that isolate plat- 
35 fomi-independent. build/t)arse module A320 ffrom platform specific message (MSG) buffers A314, A318. In this case. 
MSG buffer /V218 includes data structures for coupling data between message conversion module A304 and DBMS 
A380 in a format consistent with that of database A390. MSG buffer A218 provides a buffering function for message 
packets inbound ffrom transaction management system A150 and outbound to transaction management system A150. 
Ust_buik1 module A330 and MMS A340 also provide essentially the same functions as their counterpart modules A230. 
40 A240 on AS/400 A1 12. 

[0114] Message conversion module A304 also differs from messaging system A120 in that it uses a segment cache 
A354 and segment cache interlace structure (SCIS) A352 to facilitate access to the information data dictionary (DD) 
A326 without including the entire file in Build/parse module A220. SCIS A352 includes information for tracking accessed 
data segments in segment cache A354. This is an alternative configuration to that employed on AS/400 A112. but it 

45 requires sufficient memory for segment cache A354. 

[0115] While the configuration of computer system A100 shown in Fig. 6 provides the necessary communication 
between an RPG application A1 10 and transaction services A1 70. it does not provide security or accounting functions 
where transaction management system A150 is TOP END (TE) and IF A142 is an irtoound agent (lA) spawned by net- 
work services module A1 40 when messaging system A120 is initialized. In particular, lA A142 is configured to map all 

so conversations/dialogues having the same transaction program name (TE sign-on name) and transaction code (Request 
Service Name) to a generic userid. Consequently, all users of a given service application 310 will be assigned the same 
userid. independent of which user(s) of RPG application A1 10 actually initiated the transaction. If not addressed, this 
circumstance effectively eliminates security checking and accountability for transactions to server A192. 
[0116] In order to ensure both security checking and accountability for transactions to server A192, the preferred 

55 embodiment of system A100 incorporates a security sennce (SIGNON SECURITY SERVICE. SSS) A154 in the TE 
transaction management system A150 on gateway server A152. Referring now to Rg. 12. there is shown a b\ock dia- 
gram of a preferred configuration for gateway server A152. in which transaction management system A150 is coupled 
to transaction services A160 through SSS A1 54. SSS A154 comprises a TE client A156 and a TE server A156' coupled 
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back-to-back through a client/server interface (CSl) provided by transaction management system A150. 
[0117] lA A142 Incorporates an integral client which accesses SSS A154 through transaction management system 
A1 50 on behalf of messaging system A1 20. On initialization of messaging system A1 20, network services module A1 40 
spawns lA A1 42, which forwards a SIGNON message, including a non-generic userid to transaction management sys- 
tem A150. I A A142 establishes a dialogue with SSS A154 by passing a request for SSS services through transaction 
management system A150. using the generic userid provided in the configuration file of lA A142. Transaction manage- 
ment system A1 50 fonwards the request to SSS A1 54. establishing a dialogue between TE server A156 and RPG appli- 
cation Alio (via messaging system A120). TE server A156 then triggers TE client A156' to sign onto transaction 
management system A150 using the non-generic userid embedded in the signon message. SSS A154 confirms to 
messaging system A120 that the dialogue has been established, and sets a flag holding the dialogue open. Thereafter, 
transaction services A1 70 are accessed by TE client A156' in response to message packets (I) from messaging system 
A120. 

Claims 

15 

1 . A computer-implemented method for differentiating a customer from other customers at any of a plurality of casino 
properties, the method comprising: 

monitoring betting activity of the customer at a plurality of the casino properties; 
20 determining at least one of: 

a theoretical win profile for the customer as a function of estimated winnings from the monitored betting 
activity of the customer at the plurality of casino properties over a time period, the theoretical win profile 
for subsequently determining complementaries or services to be provided to the customer; or 
25 an accumulated point k>alance for the customer according to a monetary value of the monitored betting 

activity of the customer at the plurality of casino properties; 

establishing a status of the customer as a function of at least one of the theoretical win profile or the accumu- 
lated point balance, the status selected from a group including at least a special status and a non-special sta- 
tus; 

detecting the customer at a physical instrumentality at any one of the casino properties; 
determining the status of the customer; arxl 

responsive to the status of ttie customer being a special status, activating the physical Instrumentality for the 
benefit of the customer. 

2. The method of claim 1 . further comprising: 

responsive to the status of the customer being a special status, providing a distinguished service to the cus- 
tomer, the distinguished service limited to customers having the special status. 

40 

3. A computer-implemented method fbr differentiating a customer from other customers at a casino property, the 
method comprising: 

monitoring betting activity of the customer at the casino property; 

periodically updating a theoretical win profile for the customer as a function of estimated winnings from the 
monitored tjetting activity of the customer at the casino property over a time period, the theoretical win profile 
for subsequently determining complementaries or services to be provided to the customer; 
detecting the customer at a physical instrumentality at the casino property; 
determining the status of the customer; and 

responsive to tiie status of the customer being a special status, activating the physical Instrumentality for the 
benefit of the customer. 

4. The method of dalm 3. further comprising: 

55 responsive to the status of the customer being a special status, providing a distinguished service to the cus- 

tomer, the distinguished service limited to customers having the special status. 

5. The method of dalm 3 or 4, further conpristng: 



45 
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accumulating points of the customer according to a monetary value of the monitored betting activity of the cus- 
tomer at the plurality of casino properties; and 

establishing the status of the customer as a function of the accumulated points. 

6. The method as in one of the preceding claims, wherein detecting the customer at a physical instrumentality com- 
prises: 

detecting a customer identity card storing data identifying a customer account of the customer. 

7. The method as in one of the preceding claims, further comprising: 

providing a gaming machine and light coupled to the gaming machine, the light being selectively activateable; 
and 

wherein activating the physical instrumentality for the benefit of the customer comprises activating the light. 

8. The method as in one of the preceding claims, further comprising: 

providing a gaming machine and telephone adjacent to the gaming machine, the telephone being activateable; 
and 

wherein activating the physical Instrumentality for the benefit of the customer comprises activating the tele- 
phone. 

9. The method as In one of the preceding claims, further comprising: 

providing a gaming machine and a cat>lnet adjacent to the gaming machine, the cabinet having an Interior com- 
partment with a selectively activateable lock; and 

wherein activating the physical instrumentality for the benefit of the customer comprises enabling the lock of 
the compartment of the cabinet. 

10. The method as in one of the preceding claims, further comprising: 

providing a privileged facility with a door having a selectively activateable lock to allow customers having the 
special status into the privileged facility; and 

wherein activating the physical instrumentality for the benefit of the customer comprises unlocking the door of 
a privileged facility to allow a customer having the special status to enter the privileged facility. 

11. The method as in one of the preceding claims wherein providing a distinguished service comprises: 

providing the customer with an express food or beverage service. 

12. The method as in one of the preceding claims, wherein providing a distinguished service conprises: 

providing the customer with preferred seating at an entertainment establlsment. 

13. The method as in one of the preceding claims, wherein providing a distinguished service comprises: 

providing the customer with preferred seating at a dining establishment 

14. The method of daim 1 or 2. wherein periodically updating the theoretical win profile of the customer comprises: 

updating the theoretical win profile for each separate visit of the customer to any of one of the casino proper- 
ties. 

15. The method as in one of claims 3-13. wherein periodically updating the theoretical win profile of the customer com- 
prises: 

updating the theoreticaJ win profile for each separate visit of the customer to the casino property. 
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16. The method of one of claims 1 , 2 or 14 further comprising: 

at each of the plurality of casino properties, providing a computer-implemented management system, at least 
one input device coupled to the management system for transferring activity data of a customer to the manage- 
£ ment system, and a physical instrumentality proximate the input device, 

providing a central database server and coupling the management system of each casino property to the cen- 
tral database server; 

at each of the plurality of casino properties, assigning a customer ID and a corresponding customer account 
to each of a plurality of customers at the casino property, and storing the customer ID and corresponding cus* 
10 tomer account assigned at the casino property in the management system at the casino property each cus- 

tomer account at a casino property including at least one of the accumulated point balance from betting activity 
of the customer at that casino property or the theoretical win profile of the customer; 

forming, from the customer accounts in each of the management systems at the plurality of casino properties, 
a database of customer accounts In the central datat)ase server, each customer account in the database 
15 accessible through the corresponding customer ID. each customer account in the central database including a 

status field indicating the status of the customer as a function of either the accumulated point balance or the 
theoretical win profile of the customer; 

and wherein determining the status of the customer and activating the physical instrumentality comprises: 

20 monitoring at least one input device at a casino property for activity data of a customer, including a cus- 

tomer ID. to detect a presence of the customer; 

responsive to detecting a customer ID. determining whether the corresponding customer account Is acti- 
vated in the management system of the casino property; 

responsive to determining that the corresponding customer account is activated in the management sys- 
25 tern, updating the corresponding customer account with the activity data of the customer monitored at the 

input device; arxl 

responsive to determining that the coffesponding customer account Is not activated in the management 
system, copying selected activity data of the customer from the corresponding customer account in the 
central database server to the managemerit system at the casino property to activate the customer 
30 account in the management system at the casino property, the selected activity data including the status 

field of the customer account. 

1 7. The method of one of claims 3-1 3 or 1 5 further comprising: 

35 providing at the casino property, a computer-implemented management system, at least one input device cou- 

pled to the management system for transferring activity data of a customer to the management system, and a 
physical instrumentality proximate the Input device, 
coupling the management system to a central database sewer; 

assigning a customer ID and a corresponding customer account to each of a plurality of customers at the 
40 casino property, and storing the customer ID and corresponding customer account assigned at a casino prop- 

erty in the management system at the casino property, each customer account at each casino property includ- 
ing the theoretical win profile for the customer; 

estat>lishlng the status of the customer in the customer account as a function of the theoretical win profile of 
the customer, and wherein detecting the customer comprises: 

45 

monitoring at least one input device at the casino property for activity data of a customer, including a cus- 
tomer ID to detect a presence of the customer: 

responsive to detecting a customer ID. determining the status of the customer in the customer account. 

so 18. A system for differentiating a customer from other customers at any of a plurality of casino properties using cus- 
tomer accounts associated with customer IDs, the system comprising: 

a local computer system at each of the casino properties; 

at least one input device at each casino property, each input device coupled to the local computer system for 
55 transmitting to the local computer system, customer betting data and a customer ID received at the input 

device; 

a management system coupled to each of the local computer systems for receiving the customer betting data 
and customer ID of a customer from an input device, the management system being further coined to a cen- 
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tral database for selectively providing the received customer betting data and customer ID to the central data- 
base, and for providing a status signal indicating the status of the customer; 

at least one physical Instrumentality at each casino property, each physical instrumentality located proximate 
to the input device receiving a customer ID. and coupled to a logic unit that receives the status signal from the 
management system and selectively activates the physical instrumentality in response to the status signal incB- 
cating a customer having a special status; and 
the central database comprising: 

a plurality of customer accounts for the customers, each customer account of a customer including: 

a customer ID; 
at least one of: 

a theoretical win profile for the customer as a function of estimated winnings from the betting 
activity of the customer at the plurality of casino properties over a time period, the theoretical win 
profile for subsequently determining conrplementaries or services to be provided to the customer; 
or 

an accumulated point balance from betting activity of the plurality of casino properties; 

a status field indicating the status of the customer as a function of at least one of the theoretical win 
profile or the accumulated point balance, the status selected from a group including at least a special 
status and a non -special status; and 

a database management program for receiving customer betting activity data and a customer ID for a cus- 
tomer from a management system, updating either the theoretical win profile or the accumulated point bal- 
ance as a function of the received betting activity data, and updating the status field of the customer in the 
customer account in the central database corresponding to tiie received customer ID as a function of the 
updated theoretical win profile on the accumulated point balance. 

19. A system for differentiating a customer from other customers at a casino property using customer accounts asso- 
ciated witii customer IDs. tiie system comprising: 

a local computer system at the casino property; 

at least one input device at the casino property, each input device coupled to the local computer system for 
transmitting to the local computer system, customer betting data and a customer ID received at the input 

device; 

a management system coupled to the local computer system for receiving tiie customer betting data and cus- 
tomer ID of a customer from an input device, the management system being further coupled to a local data- 
base for selectively providing the received customer betting data and customer ID to the local database, and 
for providing a status signal indicating tiie status of the customer; 

at least one physical instrumentality at the casino property, and proximate to tiie input device receiving a cus- 
tomer ID, and coupled to a logic unit tiiat receives the status signal from the management system and selec- 
tively activates the physical instrumentality in response to the status signal indicating a customer having a 
special status; and 
tiie local database comprising: 

a plurality of customer accounts for the customers, each customer account of a customer including: 

a customer ID; 

a theoretical win profile for the customer as a function of estimated winnings from the betting activity 
of the customer at the of casino property over a time period, the theoretical win profile for subse- 
quentiy determining complementaries or services to be provided to the customer; and 
and status field indicating the status of the customer, the status selected from a group including at 
least a special status and a non-special status; 

a database management program for receiving customer betting activity data and a customer ID for a cus- 
tomer from a management system, and updating the status field of the customer in the customer account 
in the local database oorresponding to the received customer ID as a function of the theoretical win profile. 
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20. The system of claim 1 8 or 1 9, wherein the physical instrumentality connprises a light coupled to a gaming machine, 
the light being selectively activateable In response to an activation signal from the logic unit. 

21. The system of claim 18 or 19. wherein the at least one physical instrumentality comprises a telephone adjacent to 
5 a gaming machine, the telephone being selectively activate-able in response to an activation signal from the logic 

unit. 

22. The system of daim 18 or 19. wherein the at least one physical instrumentality comprises a cabinet adjacent to a 
gaming machine, the cabinet having an interior compartment with a lock that is selectively activateaWe in response 

10 to an activation signal from the logic unit. 

23. The system of claim 18 or 19. wherein the at least one physical instrumentality comprises a privileged facility with 
a door having a lock that is selectively activateable in response to an activation signal from the logic unit to allow a 
customer having a special status into the privileged facility. 

24. The system of one of claims 18-23 , further comprising: 

a logic unit communicatively coupled to the management system to receive the activation signal; 
a relay unit having a plurality of relays for selectively activating a physical instrumentality coupled to one of the 
20 relays in response to the activation signal; 

wherein the at least one physical instrumentality comprises: 

a light coupled to a relay, the light being selectively activateable in response to the activation signal; and 
a telephone coupled to a relay, the telephone being selectively activateable in response to the activation 
25 signal. 

25. A gaming machine for use in a computer system including a database of customer accounts, each customer 
account including a status of the customer, the gaining machine comprising: 

30 a card reader coupled to the computer system to read customer identity information from a customer identity 

card and provide the customer identity information to the computer system; 

a logic unit coupled to receive a status signal from a computer system indicating the status of the customer, 
and to selectively provide an activation signal in response to the status of the customer being a special status; 
a relay unit having a plurality of relays, and coupled to the logic unit to receive the activation signal and selec- 
ts tively activate at least one of the plurality of relays; and 

at least one physical instrumentality coupled to one of the relays. 

26. The gaming machine of claim 25. wherein at least one of the physical instrumentalities comprises a light coupled 
to a gaming machine. 

40 

27. The gaming machine of one of claims 25-26. wherein at least one of the physical instrumentalities comprises a tel- 
ephone adjacent to a gaming machine. 

28. The gaming machine of any one of claims 25-27. further conprising: 

45 

a cabinet adjacent to a gaming machine, the cabinet having an interior compartment with a lock coupled to one 
of the relays. 

29. A computer-implemented method for differentiating a customer from other customers at a casino property, compris- 
50 ing: 

operating a computer system including a database of customer accounts for a plurality of customers, each cus- 
tomer account of a customer having: 

55 customer identity data of the customer; 

a theoretical win profile for the customer as a function of estimated winnings from the betting activity of the 
customer at the casino property over a time period, the theoretical win profile for subsequently determining 
complementzu-ies or services to be provided to the customer; and 
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a status field indicating the status of the customer, the status selected from a group including at least a 
special status and a non-special status, 

periodically updating the status in the customer account of a customer as a function of a current theoretical win 
5 profile of the customer; 

providing a gaming machine comprising a card reader and a light; 

reading at the card reader of the gaming machine a customer identity card of a customer to obtain customer 
identity data encoded thereon; 

determining a status of the customer account corresponding to the read customer identity data; 
10 responsive to the status of the customer being a special status, activating the light at the gaming machine; and 

providing a distinguished service to the customer at the gaming machine, the distinguished service limited to 
customers having the special status. 
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